This looks good.
One small nit: could you double the times in the comments on lines 161 and 163,
just so they remain consistent?
Thanks.

This looks good. One small nit: could you double the times in the comments on lines 161 and 163, just so they remain consistent? Thanks.

Unfortunately the CI still fails :(

https://github.com/google/nsync/actions/runs/9774034844/job/26981440061

5/26 Test  #5: cv_test ..........................***Failed   21.27 sec
cv_test                   test_cv_producer_consumer0                     passed 657.84ms
cv_test                   test_cv_producer_consumer1                     passed  71.27ms
cv_test                   test_cv_producer_consumer2                     passed  13.76ms
cv_test                   test_cv_producer_consumer3                     passed  11.69ms
cv_test                   test_cv_producer_consumer4                     passed  12.29ms
cv_test                   test_cv_producer_consumer5                     passed  11.27ms
cv_test                   test_cv_producer_consumer6                     passed  12.16ms
cv_test                   test_cv_deadline                               
error: /Users/runner/work/nsync/nsync/testing/cv_test.c:[24](https://github.com/google/nsync/actions/runs/9774034844/job/26981440061#step:4:25)6: nsync_cv_wait() returned too late 28 times
cv_test                   test_cv_deadline                               failed    9.07s
cv_test                   test_cv_cancel                                 passed    9.05s
cv_test                   test_cv_debug                                  passed    2.31s
cv_test                   test_cv_transfer                               passed  34.79ms

That's saying that the system scheduled a thread more than 100ms later than requested, 28 times out of 50 attempts.
That test is pretty reliable on a normal system, which suggests that github's test machines are exceptionally
bad at scheduling threads promptly.

I suppose it would be possible to relax the constraints of this test too (plus the mu_test),
but then the tests would become pretty meaningless on systems with tighter scheduling bounds.

One alternative might be to pass a flag like "-DVERY_SLOW_TEST_MACHINE" to the compilers
by using the CMAKE_C_FLAGS_INIT and CMAKE_CXX_FLAGS_INIT omn the cmake command line from the ci.yml file.

The in the tests, it would be possible to write something like this:

#if defined(VERY_SLOW_TEST_MACHINE)
#define ....
#else /* a normal machine that isn't very slow */
#define ....
#endif

and set the parameters so that things still work on the github ci machines.

Can you think of a better approach?

P.S. If we use something like VERY_SLOW_TEST_MACHINE, we ought to spell it "NSYNC_VERY_SLOW_TEST_MACHINE"

@m3bm3b I have update the MR with a new NSYNC_TESTING_SLOW_MACHINE CMake variable.
That set a NSYNC_TESTING_SLOW_MACHINE compile definition variable.

Feel free to rename / update if you think of a better naming

As I look at the other tests, I see there will be several that will need changing.
I'll make those changes first, and then you can enable the CI, if that's ok with you.